System and method for providing a roster list of temporary contacts having expiration periods designated by a user in an instant messaging environment

ABSTRACT

A system for providing temporary contact aliases is provided. A representative system includes a database system operable to store at least one resource list comprising a plurality of contacts associated with at least one user. The plurality of contacts comprising at least one temporary contact at the instruction of said at least one user, stored in said at least one resource list associated with said at least one user. The system further includes a network interface operable to communicate with a plurality of users, including said at least one user, over a network which is operable to provide a communication medium between the plurality of users. Methods and other systems for temporary contact alias are also provided.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to copending U.S. provisionalapplication entitled, “INTEGRATION OF INSTANT MESSAGING AND COMPUTEROPERATING SYSTEMS,” having Ser. No. 60/382,106, filed May 21, 2002,which is entirely incorporated herein by reference.

FIELD OF THE INVENTION

The present invention is generally related to telecommunications andmore particularly to services provided to clients via instant messagingapplications.

DESCRIPTION OF THE RELATED ART

The development of the internet has driven vast technologicaldevelopments, particularly in the areas of networking hardware andsoftware. Networking hardware developments have enabled networks totransfer large files in fractions of a second. Software developments,such as the world-wide-web (web) and e-mail, have facilitatedcommunications over these networks have allowed users to remain inalmost constant contact with work. These types of communications havebecome of utmost importance in the business setting, where response timehas become a key survival factor for many companies. Other networkingsoftware has allowed users to access and run applications from remotelocations. Thus allowing a businessperson to remain productive, evenwhile away on a business trip.

Moreover, the internet has changed the way people communicate. E-mailhas become the dominant means of communications in many settings, beingpreferred over traditional mail, and even telephones in some cases.Almost instantaneous transportation with little charge has driven muchof the popularity of e-mail. Once used only in university and militarysettings, e-mail has gained widespread public acceptance in just overtwenty years.

In a world economy based upon communication, the relative speed ofe-mail in comparison to traditional mail is no longer fast enough.Demand for faster access to more information has resulted in thedevelopment of a number of instant messaging (IM) services. IM bringspresence information into the communications arena, and allows users tohave real-time chat sessions with other users who are present on thesystem. The real-time nature of IM has quickly lead to acceptance frommany in the business community as an invaluable tool for communication.However, there has been no tool that has integrated the computer and theIM services.

Therefore, there is a need for systems and method that address theseand/or other perceived shortcomings of the prior art.

SUMMARY OF THE INVENTION

One embodiment, among others, of the present invention provides systemsand methods for providing temporary contact aliases in a resource list.A representative system includes a database system operable to store atleast one resource list comprising a plurality of contacts associatedwith at least one user. The plurality of contacts including at least onetemporary contact at the instruction of said at least one user stored insaid at least one resource list associated with said at least one user.The system further includes a network interface operable to communicatewith a plurality of users, including said at least one user, over anetwork which is operable to provide a communication medium between theplurality of users.

A method, among others, to store temporary contacts includes: receivinga request from a user to add a temporary contact to a network resourcelist associated with the user; storing the temporary contact in thenetwork resource list; and, removing the temporary contact uponexpiration of the temporary contact.

A method, among others, to create temporary contacts includes: sending arequest to a database system to create a temporary contact on a networkresource list; and providing a set of details about the temporarycontact.

Other systems, methods, features, and advantages of the presentinvention will be or become apparent to one with skill in the art uponexamination of the following drawings and detailed description. It isintended that all such additional systems, methods, features, andadvantages included within this description and within the scope of thepresent invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood with reference to the followingdrawings. The components in the drawings are not necessarily to scale,emphasis instead being placed upon clearly illustrating the principlesof the present invention. Moreover, in the drawings, like referencenumerals designate corresponding parts throughout the several views.

FIG. 1A is a block diagram illustrating an interoperability architecturefor instant messaging used in one embodiment, among others, of thepresent invention.

FIG. 1B is a block diagram illustrating an alternative embodiment, amongothers of an interoperability architecture for instant messaging used inone embodiment, among others, of the present invention.

FIG. 2 is a block diagram of the interoperability architecture used inone embodiment, among others, of the present invention.

FIG. 3 is a block diagram showing an embodiment, among others, of asystem of the present invention for providing temporary instantmessaging contact aliases.

FIG. 4 is a flowchart illustrating an embodiment, among others, of theoperation of the system of FIG. 3.

FIG. 5 is a flowchart illustrating an embodiment, among others, of amethod of using the system of FIG. 3.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The preferred embodiments of the present invention now will be describedmore fully with reference to the accompanying drawings. The inventionmay, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein; rather, theseembodiments are intended to convey the scope of the invention to thoseskilled in the art. Furthermore, all “examples” given herein areintended to be non-limiting.

Referring now to FIG. 1A, shown is a block diagram illustrating aninteroperability architecture for instant messaging used in oneembodiment, among others, of the present invention. Each of a pluralityof remote computers 100 a–i access a network 110 through a localinternet service provider (ISP) server 120 a, 120 b, 140. The local ISP120 a, 120 b, 140 can offer network 110 access through myriad connectiontypes, including a digital subscriber line (DSL) service, an integratedservices digital network (ISDN) service, an analog dial-up service,ethernet, T-1, or any other service for transmitting data through anetwork 110. Universal servers 130 a–c are located between the internetand each of local ISP servers 120 a, 120 b, and located inside local ISP140. These universal servers 130 a–c provide interoperability between aplurality of proprietary instant messaging clients 100 a–i. Of course,the scope of the presentation includes networks other than those withuniversal servers or instant messaging.

Referring now to FIG. 1B, shown is an illustration of an alternativeembodiment, among others, of a universal architecture. Greater detailregarding this interoperability architecture may be found in U.S. patentapplication Ser. No. 10/135,929, entitled “Instant MessagingArchitecture and System for Interoperability and Presence Management,”which is hereby incorporated by reference. The universal architectureuses a universal protocol, such as the extensible markup language (XML)protocol to allow users of different ISPs 120 a, 140 that useproprietary protocols to communicate with one another. Universal servers130 a, 130 c located at each of the ISPs 120 a, 140 are the key featureof the universal architecture. FIG. 1B illustrates two separate ISPnetworks 120 a, 140. The discussion of the ISP 120 a, 140 will belimited to the components that provide the universal service.

The ISP 120 a contains a local IM server 150 a, and is connected to theuniversal server 130 a. The local IM server 150 a provides the standardIM function for the ISP 140 a. The universal server 130 a provides theuniversal function that allows the first user 160 a, who is registeredwith the first ISP 120 a, to communicate with a second user 160 bregistered with the second ISP 140. The first ISP 120 a providesconnections to a plurality of clients 170 a, 170 b on computers 100 a,100 b, which allows users 160 a, 160 b to access the proprietary IM anduniversal functions of the ISP 120 a. The first ISP 120 a is “bimodal,”in that it uses both a proprietary and universal format to provide aproprietary IM function that only allows the users who are registeredwith the ISP 120 a to send and receive instant messages. For example, ifonly one user has registered with the universal server 130 a, then thelocal IM server 150 a will transfer instant messages between the firstand second users 160 a, 160 b using the proprietary protocol. However,if both the first and second users 160 a, 160 b are registered with theuniversal server 130 a, then the first ISP 120 a can transfer instantmessages between them using the universal protocol. By supporting bothformats at the first ISP 120 a, users can migrate to the universalformat over time. When all users 160 a, 160 b have migrated theproprietary format can be discontinued.

The universal server 130 a removes the restrictions associated withproprietary IM functions associated with the ISP 120 a. The universalserver 130 a uses a universal format, such as XML, or any other suitableformat, that allows users 160 a, 160 b registered with an ISP 140 a,such as BellSouth DotNet, to send and receive instant messages fromother users 160 c, 160 d registered with another ISP 140 b, such asAmerica Online (AOL).

The user 160 a accesses the local IM server 150 a of the ISP 120 athrough the IM client 170 a located on the user's computer 100 a. The IMclient 170 a typically includes a proprietary software program that iscapable of opening communications sockets that allow the IM client 170 ato communicate with the local IM server 150 a using either theproprietary or universal protocols. The software program is capable offormatting an instant message sent from the IM client 170 a to theappropriate format used by the IM function of the ISP 120 a. In thismanner, the user 170 a is capable of communicating with any other user160 b registered with the ISP 120 a. However, the local IM server 150 aon a first ISP 120 a is also connected to a first universal server 130a. The first universal server 130 a is in turn, connected to a seconduniversal server 130 b on the second ISP 140 b via a distributednetwork, such as the internet 110. This allows the user 160 a tocommunicate not only with the user 160 b who is registered with thefirst ISP 120 a, but also with users 160 c who are registered with thesecond ISP 140 that uses a different proprietary IM protocol to send andreceive instant messages within the network of the second ISP 140.

In order for the first user 160 a to be able to send and receivemessages with a third user 160 c on the second ISP 140, the IM client170 a must be able to identify the IP address and presence informationassociated with the third user 160 c. The presence information for thethird user 160 c is stored on the universal server 130 a connected tothe first ISP 120 a. The universal server 130 a on the first ISP 120 astores the IP address and presence information for the third user 160 c.Therefore, the first user 160 a, who is registered with the universalserver 130 a on the first ISP 120 a has access to the IP address andpresence information of the third user 160 c.

One skilled in the art will recognize the difference between the firstlocal ISP 120 a and the second ISP 140. The second local ISP 140 is analternative embodiment that includes within the ISP 140 both theuniversal server 130 c and a local IM server 150 b. Here, the local IMserver 150 b does not communicate with the universal server 130 c. Thus,the first user 160 a will not be able to communicate with a fourth user160 d if the fourth user 160 d is not registered with the universalserver 130 b, but instead is only registered with a local IM server 150b. As a result, the fourth user 160 d is able to send and receiveinstant messages using only the proprietary format over local IM server150 b. Therefore, the user 160 d is limited to communicating via instantmessages with users of the second ISP 140 b, such as the third user 160c.

An advantageous feature of the universal architecture is that it isdesigned to be easily integrated within existing ISPs 120 a, 140, suchas AOL and Microsoft Network (MSN) without disrupting the current IMfunction of these ISPs 120 a, 140. Each ISP 120 a, 140 that adopts theuniversal architecture requires only a slight modification to theexisting network. The ISP 120 a, 140 either adds a universal server 130a between the local IM server 150 a and the internet 110, or adds anadditional server to function as the universal server 130 b and caninstall a universal application program on the local IM server 150 a,150 b and each IM client 170 a–d attached to the network. The universalapplication program that is installed at each ISP 120 a, 140 convertsthe ISP 120 a, 140 to function as “bimodal.” That is, the ISP 120 a, 140is capable of using the proprietary IM protocol of the local IM server150 a, 150 b and the universal protocol of the universal architecture.The bimodal nature of the universal architecture allows the universalserver 130 a, 130 b to be implemented into existing ISPs 120 a, 140 suchas AOL and MSN without disrupting the current proprietary IM functionsof those services. This allows the current users 160 a–d to continueusing the proprietary IM function of their particular ISP 120 a, 140until every user 160 a–d can be converted to the universal protocol.

Referring now to FIG. 2, shown is a block diagram illustrating anembodiment, among others, of the universal server 130 of FIGS. 1A & B,which is used in conjunction with an embodiment, among others, of thepresent invention. The client 170 includes at least three layers offunctionality in one embodiment, among others, to communicate with theuniversal server 130. The first layer is the presentation layer 205. Thepresentation layer 205 includes the logic that is used to present theinstant messenger or another application to a user. The second layer isa middleware layer 210. The middleware layer 210 includes logic used tohandle the message routing of the instant messaging application betweenthe presentation layer and the service layer. The third layer is theservice layer 215. The service layer 215 handles both the applicationsmanagement and communications management of the client. The servicelayer 215 communicates with the communications layer 220 on theuniversal server 130.

Preferably, there are three basic layers to the instant messagingservice. The first layer is the communications manager (CCM) 220. Thecommunications manager 220 manages the connections between the clientcommunications manager 215 and the universal server 130. In oneembodiment, among others, of the universal server 130, communicationsbetween the client service layer 215 and the universal server 130communications manager 220 occur in extensible markup language (XML).Further, the communications may be secure socket layer (SSL) encryptedfor security. Moreover, the communications can be compressed by acompression/decompression algorithm implemented on acompression-decompression module, more commonly referred to as a CODEC,to provide faster data transfer.

The communications manager 220 includes a number of connection socketsbetween the communications manager 220 and a plurality of users. Thecommunications manager 220 can further include a load balancer (notshown) to balance the connections over a number of differentcommunications managers. The load balancer can maintain a connection tothe same connection socket during the period while the user is logged onand connected to an operable communications manager 220, and canautomatically connect the user to an alternate connection socket when acommunications manager might fail. Thus, a continuous connection can bemaintained during an active session despite hardware failures. The loadbalancer can also protect the server against denial of service attacks,which have become increasingly prevalent on the internet.

A standard communications manager 220 will typically attempt to recoverand reallocate a connection socket after a period of time with noactivity from the client 170. In this situation the communicationsmanager 220 assumes that the client is no longer present on the system.However, because presence is an important piece of the instant messagingarchitecture, the communications layer 215 on the client-side sends asignal to the universal server 130 to keep the connection socket activeon the communications manager 220.

The second layer is the service router 225, with one example known as aJabberD in the Jabber architecture, such as that available from Jabber,Inc. of Denver, Colo., which performs a similar function to the messagerouter 210 on the client side of the network. A number of differentservice managers 230 can be coupled to the service router 225, each ofwhich can provide a different service to the client 170 over theinternet. Thus when a service is requested, the service router 225routes the request to the requested service manager 230. In the instantmessaging architecture the service manager 230 is a Jabber servicemanager (JSM) which allows text communication between parties. The JSM230 also keeps track of presence and roster information 235, 240,respectively, for a particular user on the network who has logged intothe instant messaging system. Presence 235 typically refers to theuser's status on the network, while roster 240 typically refers to thestatus on the network of those on the user's resource list.

Similarly to the communications manager 220, the service router 225 canutilize a self-similar architecture using the CODEC (not shown) and loadbalancer (not shown) to optimize the connection between thecommunications manager 220 and the service router 225. Use of the CODECenables high speed data transmission between the communications manager220 and the service router 225. The load balancer provides a robustnessthat allows the client to maintain contact with a selected servicemanager 230 during a session.

In one embodiment, among others, of the universal server 130, thedatabase containing the non-persistent data, such as presence and rosterinformation 235, 240, can be severed from the service manager 230. Thepresence information 235 typically includes a list of all users who areregistered with the universal server 130, while the roster list includesa non-persistent list of those resource which are present on thenetwork. Thus, the non-persistent data can be maintained and updated ata single database, and the plurality of service routers 225 can connectto the same presence information 235. After severing this database fromthe service manager 230 the service manager 230 can be equipped, asdescribed above, with a CODEC (not shown) and load balancer (not shown),again utilizing a self-similar architecture to provide quality ofservice and communication efficiencies.

The service router 225 is further coupled, in one embodiment, amongothers, to an XML database (XDB) library 245. The XDB library 245 isused as a translator such that the service router 225 can communicatewith a database system 250 that includes persistent data relating to aplurality of clients. The database system 250 which contains most of thepersistent data for the services on the network, such as resource lists,preferences, etc. In one embodiment, among others, of the universalserver 130 the database system 250 can be an Oracle 9i database. The XDBlibrary 245 can be further coupled to an authentication server, such asa username and password database 255. Thus a username and password canbe required before the user is authenticated and allowed to access thedatabase system 250 for any profile information.

After registering with the database system 250, the user is providedwith a resource list. The client 170 can then contact the servicemanager 230 to find out which of the resources on the resource list ispresent and/or available on the network. Typically, presence refers tothe registration state of a client 170. If a client 170 is logged-in tothe network, the client 170 is present on the network. Typically,availability refers to the status of a user at the client computer. Auser can be made unavailable by the network if there has been noactivity on the client computer 170 for a period of time. Otherwise, aclient 170 can be made unavailable by user choice, if the user does notwish to be disturbed. One skilled in the art will recognize that theseare merely definitions of various states that can be defined accordingto any specific implementation of the presence and roster databases 235,240. Furthermore, these databases 235, 240 that contain non-persistentinformation could keep track of any other states that might be definedby the specific implementation of the service manager 230.

Typically with respect to other instant messaging systems, the resourcelist only comprises a list of other users for which the client 170wishes to know the status. However, the resource list of someembodiments of the present invention could include access to a pluralityof applications, and there could be multiple service managers thatinclude managers for the plurality of applications coupled to theservice router 225. These service managers could provide access to amultitude of different applications and resources, such as MicrosoftWord and/or Visio, provided by Microsoft Corp. of Redmond, Wash., and/orbilling entry applications, etc. Moreover, the Jabber service manager230 could keep track of the presence of these other applications andother resources on the network. For example, if a client wished toaccess an e-mail account from a remote location and the system was down,the Jabber service manager 230 could alert the user that the server wasdown. Thus the client 170 would not waste resources searching andwaiting for e-mail from a server that is off-line.

Thus, Jabber can be used similarly to an operating system. When aresource server 260 is present on the network, the resource(s)associated with that resource server can be displayed as an icon on theclient computer display, and when a resource server is down, theresource(s) can be removed from the client computer 170 display. Thus,icons, for example, could appear and disappear from a client computer170 display as they become present and available, and not present orunavailable. Selecting the icon while it is displayed will cause arouting request to be sent to the service router 225. Upon receiving therouting request, the service router 225 will determine the correctrouting of the routing request and deliver the proper service to theclient computer 170.

Referring now to FIG. 3, shown is a block diagram illustrating anembodiment, among others, of a system of the present invention forproviding temporary contact aliases. In this embodiment, the universalserver 130 includes a database system 250′, which is operable to store atemporary contact alias 300 for a limited duration. When the temporarycontact 300 expires, the temporary contact alias 300 is removed from theclient resource list 305.

In one embodiment, among others, of the present invention a temporarygroup 310 can be added to the client profile 315. The temporary group310 will include contact aliases 320, 325 which the user desires to keeponly for a limited period of time. The temporary group 310 couldcontain, for example, aliases 300, 320 linked to respective uniqueidentifications 325, 330, such as a jabber identification or e-mailaddress, and respective expiration periods 335, 340. The user couldspecify the expiration period 335, 340 or the universal server 130 coulddefault to some period of time, both of which could be extendableindefinitely by the user through the client 200. Such a system could beuseful in keeping a resource list 305 from becoming cluttered andunusable. Furthermore, it allows the client to control how long acontact 300 is stored in his or her profile 315 without requiring theuser to actively monitor and remove old contacts.

In one embodiment, among others, of the present invention, the usercould add a temporary contact 300 to his/her resource list 305 bysearching for a user and use a drag-and-drop mechanism to add thecontact 300 into the user's temporary group folder 310. Upon an attemptto add the contact 300 to the temporary group 310 in this manner, theuniversal server 130 would prompt the user to enter an expiration timeor event 335. Alternatively, the user could add a contact 300 manuallythrough a menu interface, such as by choosing to “add new contact” fromthe menu list. The universal server 130 or the client 170 applicationcould then prompt the user about the details of the contact 300,including: contact's unique identification 325, temporary status,expiration 335, etc. In a further alternative embodiment, among others,a temporary contact 300 may be added or removed by an event stimulus.Such an event stimulus could include: accepting a file transfer fromanother user; closing a service ticket; client logout; orbeginning/ending a chat session.

Furthermore, a temporary contact could be added when a first userrequests to be added to be added to a second user's resource list 305.Upon receiving this request to be added to the second user's resourcelist 305, the universal server 130 can queue a prompt for the seconduser, alerting him/her of the request to add the first user to thesecond user's resource list 305. The second user could then be given achoice as to whether or not to add the first user to his/her resourcelist 305, and moreover, whether the first user should be added to thetemporary group 310.

Typically, the temporary contact 300 can be removed through themechanism of the service manager 230. When a user logs on to theuniversal server 130, the service manager 230 reads the profile 315 fromthe database. Upon reading the profile 315 the service manager 230 couldcheck the expiration periods 335, 340 of the temporary group 310 toensure that no temporary contacts 300, 320 have expired. If any of thetemporary contacts 300, 320 have expired, the service manager 230 cansend a request to the database 250′ to remove the expired temporarycontact.

Alternatively, a server (not shown) could be attached to the database250′ which monitors the expiration of a plurality of temporary contacts300, 320. Then when an temporary contact 300, 320 expires the server canautomatically remove the temporary contact 300, 320 from the userprofile 315. Thus, the next time the user logs in to the universalserver 130, the resource list 305 sent to the client 170 will notinclude the temporary contact 300, 320.

In a further alternative embodiment, among others, of the presentinvention, the user could be prompted upon the expiration of a temporarycontact 300, but prior to the removal of the temporary contact 300. Thisprompt could afford the user the opportunity to add the temporarycontact 300 to the regular resource list 305 (i.e. no expiration) or toextend the expiration of the temporary contact. Thus, for example, ifthe user has added a temporary contact because they are having their carserviced, the temporary contact will not be automatically deleted in theevent that the service shop keeps the car longer than expected. Instead,upon the expiration of the service shop temporary contact, the servicemanager 230 could send a prompt to the user to ascertain whether thetemporary contact should be removed. So, in the situation where theservice shop is keeping the car, the user would respond to the servicemanager 230 instructing the service manager 230 to delay the expirationdate.

Referring now to FIG. 4, shown is a flowchart illustrating oneembodiment, among others, of a flowchart illustrating the operation ofthe system of FIG. 3. The first step 400 in the operation is receiving arequest to add a temporary contact 300 to the resource list 305. Theuniversal server 130 can, in the next step 410, prompt the client 170for an expiration date 335 for the temporary contact 300 to be stored inthe resource list 305. In accordance with the next step 420, a defaultexpiration period 335 for the temporary contact 300 can be set if theuser does not specify an expiration 335. When a expiration date 335 isreceived, in the next step 430, the temporary contact 300 is recordedinto the database system 250′ along with a link to the unique identifier325 and expiration date 335. The universal server 130 then checks if thetemporary contact 300 is expired, in accordance with the next step 440.If the temporary contact 300 is expired, the next step 450 is to removethe temporary contact 300 from the resource list 305. However, if thetemporary contact 300 is not expired, the universal server 130 can,according to the next step 460, wait and check for expiration again atthe next login or a regular intervals. One skilled in the art willrecognize that the universal server 130 can prompt the user about thepermanence of a contact when a request to add a contact is received bythe universal server 130. Moreover, the universal server 130 can promptthe user before removal of a temporary contact to confirm the removal orextension of an expired temporary contact.

Referring now to FIG. 5, shown is an embodiment, among others, of aflowchart illustrating a method of using the system of FIG. 3. The firststep 500 is to login to the universal server 130. The next step 510 ofthe method is to request to add a temporary contact 300 to the client170 resource list 305. This can be done automatically bydragging-and-dropping the contact into the resource list, or by merelyadding the contact manually to the resource list using the program menuinterface. Then the user can enter the expiration date/time 335 for thetemporary resource list. After entering the temporary contact uniqueidentification 325 and expiration 335, the universal server 130 will addthe temporary contact 300 to the database system 250′.

The retrieval method is not shown in the present embodiment, however,the next time the client logs-on to the universal server 130, the client170 will request its resource list 305. The service manager 230, afterreceiving the resource list 305 through the client 200, will check thetemporary group 310 to assure that none of the temporary contacts 300,320 have expired. If any of the temporary contacts 300, 320 haveexpired, the service manager 230 will send a request to the databasesystem 250′ to remove the expired contacts from the resource list 305and send an updated resource list 305 to the client computer 200. Ifnone of the contacts 300, 320 have expired, the service manager 230 willmerely send the current resource list 305, including the temporarycontacts 300, 320 to the client computer 170 with status informationregarding the resource list 305.

One skilled in the art will recognize that there are many alternativeways to design a database to implement the temporary contact aliassystems described above. Each of these alternative mechanisms to add atemporary link to a resource list are intend to be included within thedisclosure of the present application.

Process and function descriptions and blocks in flow charts can beunderstood as representing, in some embodiments, modules, segments, orportions of code which include one or more executable instructions forimplementing specific logical functions or steps in the process, andalternate implementations are included within the scope of the preferredembodiment of the present invention in which functions may be executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those reasonably skilled in the artof the present invention. In addition, such functional elements can beimplemented as logic embodied in hardware, software, firmware, or acombination thereof, among others. In some embodiments involvingsoftware implementations, such software comprises an ordered listing ofexecutable instructions for implementing logical functions and can beembodied in any computer-readable medium for use by or in connectionwith an instruction execution system, apparatus, or device, such as acomputer-based system, processor-containing system, or other system thatcan fetch the instructions from the instruction execution system,apparatus, or device and execute the instructions. In the context ofthis document, a computer-readable medium can be any means that cancontain, store, communicate, propagate, or transport the software foruse by or in connection with the instruction execution system,apparatus, or device.

It should be emphasized that the above-described embodiments of thepresent invention are merely possible examples of implementations setforth for a clear understanding of the principles of the invention. Manyvariations and modifications may be made to the above-describedembodiment(s) of the invention without departing substantially from theprinciples of the invention. All such modifications and variations areintended to be included herein within the scope of this disclosure andthe present invention and protected by the following claims.

1. A system for providing temporary contacts in a messaging environmentcomprising: an electronic chat database system for maintaining at leastone roster list of contacts for at least one user, the contactscorresponding to entities that the at least one user is capable ofcommunicating with via an electronic chat client; wherein the at leastone roster list includes at least one temporary contact and at least onepermanent contact; a service manager operable to access the at least oneroster lists list maintained in the electronic chat database system, theservice manager configured to request the electronic chat databasesystem to add a new contact to the at least one roster list of the atleast one user so that the at least one user is able to communicate withan entity associated with the newly added contact, the service managerfurther operable to request the electronic chat database system todesignate the new contact as a temporary contact, the temporary contactbeing assigned an expiration period as the temporary contact is added tothe at least one roster list and the at least one permanent contact nothaving an expiration period, wherein; prior to a scheduled removal ofthe temporary contact from the at least one roster list, the servicemanager is operable to provide the at least one user with an option toconvert the temporary contact having the expiration period to apermanent contact not having an expiration period; and after theexpiration period expires, the service manager is operable to requestthe temporary contact to be removed by the electronic chat databasesystem, the service manager being further configured to update the atleast one user as to a current network statuses of the contactscontained on the at least one roster list of the at least one user sothat the at least one user is made aware, via the electronic chatclient, of which contacts are currently available for communicating withthe at least one user.
 2. The system of claim 1, wherein individualtemporary contacts possess different expiration periods.
 3. The systemof claim 1, wherein the service manager is operable to modify theexpiration period.
 4. The system of claim 1, wherein the service manageris operable to prompt the at lease one user to specify the expirationperiod for the temporary contact.
 5. The system of claim 1, wherein theservice manager is operable to prompt the at lease one user to designatethe new contact that is being added to the at lease one roster list asbeing temporary or permanent.
 6. The system of claim 1, wherein prior toa scheduled removal of the temporary contact from the at lease oneroster list, the service manager is operable to provide an option ofextending the expiration period for the temporary contact.
 7. The systemof claim 1, wherein the service manager is operable to prompt the atlease one user to extend the expiration period of the temporary contacthas expired but before a process for removing the temporary contact hascommenced.
 8. The system of claim 1, wherein the service manager promptsthe at least one user to specify a time at which the temporary contactis to expire in a process of adding the temporary contact to the atleast one roster list of the at least one user.
 9. The system of claim1, wherein the electronic chat client is an instant messaging clientthat is configured to send a request to add the new contact to theservice manager, wherein the service manager causes the instantmessaging client to prompt the at least one user to designate the newcontact as either the temporary contact or the permanent contact, theinstant messaging client being configured to display a current networkstatus of the temporary contact and enabling communication with thetemporary contact until the expiration period of the temporary contactexpires.
 10. A method for providing temporary contacts in a messagingenvironment comprising: storing at least one roster list of contacts forat least one user, the contacts corresponding to entities that the atleast one user is capable of communicating with via an electronic chatclient wherein the at least one roster list includes at least onetemporary contact and at least one permanent contact; providing to theat least one user current network statuses of the entities associatedwith the contacts contained in the at least one roster list of the atleast one user; receiving a request to add a new contact to the at leastone roster list of the at least one user so that the at least one useris able to communicate with an entity associated with the newly addedcontact; receiving a designation for the new contact, the designationindicating the new contact is to be a temporary contact, the temporarycontact being assigned an expiration period as the temporary contact isadded to the at least one roster list and the at least one permanentcontact not having an expiration period; prior to a scheduled removal ofthe temporary contact, prompting the at least one user to choose toconvert the temporary contact to a permanent contact and to allow thetemporary contact to be removed, where the temporary contact has anexpiration period that has expired; and after the expiration period ofthe temporary contact expires, automatically removing the temporarycontact from the at least one roster list of the at least one user. 11.The method of claim 10, further comprising the steps of: detecting thatthe expiration period of the temporary contact has expired andscheduling removal of the temporary contact associated with theexpiration period; and prompting the at lease one user to extend theexpiration period of the temporary contact after the service managerdetects that the expiration period of the temporary contact has expiredbut before a process for removing the temporary contact has commenced.12. The method of claim 10, further comprising the steps of: promptingthe at lease one user to specify a time at which the temporary contactis to expire as part of a process of adding the temporary contact to theat lease one roster list of the at lease one user.
 13. The method ofclaim 10, further comprising the steps of: prompting the at lease oneuser to designate whether the new contact is to be temporary contact orpermanent contact.
 14. The method of claim 10, further comprising thesteps of: detecting an expiration of the temporary contact; andproviding an updated resource list to the at least one user, the updatedresource list no longer containing the temporary contact that hasexpired.
 15. The method of claim 10, further comprising the step of:regularly checking network statuses of the contacts contained in theupdated resource list of the at least one user and regularly providingthe at least one user current network statuses while the at least oneuser is online.
 16. The method of claim 10, further comprising the stepof: regularly checking expiration periods of the temporary contacts inthe updated resource list of the at least one user.
 17. The method ofclaim 10, further comprising the step of: enabling the at least one userto change a temporary designation of a contact after the temporarydesignation has been previously established.
 18. The method of claim 10,wherein the contacts constitute instant messaging contacts.
 19. Themethod of claim 10, further comprising the step of: automaticallyassigning an expiration period for the temporary contact that has notbeen specified by the at least one user.
 20. The method of claim 10,wherein the request to add the new contact is received from the at leastone user.
 21. The method of claim 10, wherein the request is receivedfrom another user whose contact is being added to the at least oneroster list.
 22. The method of claim 10, further comprising the step of:connecting a chat session between a first user associated with theupdated resource list and a second user of temporary contact identifiedby the first user.
 23. The method of claim 10, wherein the temporarycontact comprises a handle and communication address for communicatingwit an entity associated with the temporary contact.
 24. The method ofclaim 10, wherein individual temporary contacts possess differentexpiration periods.
 25. A computer readable storage medium having aprogram for providing temporary contacts in a messaging environment, theprogram having instructions for performing the steps of: storing atleast one roster list of contacts for at least one user, the contactscorresponding to entities that the at least one user is capable ofcommunicating with via an electronic chat client, wherein the at leastone roster list includes at least one temporary contact and at least onepermanent contact; providing to the at least one user current networkstatuses of the entities associated with the contacts contained in theat least one roster list of the at least one user; receiving a requestto add a new contact to the at least one roster list of the at least oneuser so that the at least one user is able to communicate with an entityassociated with the newly added contact; receiving a designation for thenew contact, the designation indicating the new contact is to be atemporary contact, the temporary contact being assigned an expirationperiod as the temporary contact is added to the at least one roster listand the at least one permanent contact not having an expiration period;prior to a scheduled removal of the temporary contact, prompting the atleast one user to choose to convert the temporary contact to a permanentcontact and to allow the temporary contact to be removed, where thetemporary contact has an expiration period that has expired; and afterthe expiration period of the temporary contact expires, automaticallyremoving the temporary contact from the at least one roster list of theat least one user.
 26. The computer readable storage medium of claim 25,the program further performing the steps of: detecting that theexpiration period of the temporary contact has expired and schedulingremoval of the temporary contact associated with the expiration period;and prompting the at least one user to extend the expiration period ofthe temporary contact after the service manager detects that theexpiration period of the temporary contact has expired but before aprocess for removing the temporary contact has commenced.
 27. Thecomputer readable storage medium of claim 25, the program furtherperforming the step of: prompting the at least one user to specify atime at which the temporary contact is to expire as part of a process ofadding the temporary contact to the at lease one roster list of the atlease one user.
 28. The computer readable storage medium of claim 25,the program further performing the step of: prompting the at lease oneuser to designate whether the new contact is to be temporary contact orpermanent contact.
 29. The computer readable storage medium of claim 25,the program further performing the step of: detecting an expiration ofthe temporary contact; and providing an updated resource list to the atleast one user, the updated resource list no longer containing thetemporary contact that has expired.
 30. The computer readable storagemedium of claim 25, the program further performing the step of:regularly checking network statuses of the contacts contained in theupdated resource list of the at least one user and regularly providingthe at least one user current network statuses while the at least oneuser is online.
 31. The computer readable storage medium of claim 25,the program further performing the step of: regularly checkingexpiration periods of the temporary contacts in the updated resourcelist of the at least one user.
 32. The computer readable storage mediumof claim 25, the program further performing the step of: enabling the atleast one user to change a temporary designation of a contact after thetemporary designation has been previously established.
 33. The computerreadable storage medium of claim 25, wherein the contacts constituteinstant messaging contacts.
 34. The computer readable storage medium ofclaim 25, the program further performing the step of: automaticallyassigning an expiration period for the temporary contact that has notbeen specified by the at least one user.
 35. The computer readablestorage medium of claim 25, wherein the request to add the contact isreceived from the at least one user.
 36. The computer readable storagemedium of claim 25, wherein the request is received from another userwhose contact is being added to the at least one roster list.
 37. Thecomputer readable storage medium of claim 25, further comprising thestep of: connecting a chat session between a first user associated withthe updated resource list and a second user of the temporary contactidentified by the first user.
 38. The computer readable storage mediumof claim 25, wherein the temporary contact comprises a handle and acommunication address for communicating with an entity associated withthe temporary contact.
 39. The method computer readable storage mediumof claim 25, wherein individual temporary contacts possess differentexpiration periods.